Wenui: cómo se arma un producto multicliente sobre AI Agent Builder

Wenui tiene una sola promesa: pegá tu web, conocé a tu asistente. El dueño de un negocio escribe su dirección y al rato está hablando con un asistente que ya sabe sus horarios, sus precios y cómo contactarlo. Si le gusta, confirma su correo, carga saldo prepago y pega un fragmento de código en su sitio. No hay mensualidad ni llamada de ventas.

Detrás de esa promesa, cada cliente recibe una instalación completa y configurada: su propio tenant, su propia base de conocimiento, su propio agente, una credencial para su sitio, un saldo, un inicio de sesión y un portal. Nadie configura nada de eso a mano. Wenui es un producto con marca, sitio y reglas comerciales propias, construido sobre AI Agent Builder como uno de los clientes de la plataforma; y el trabajo de convertir una configuración en muchos clientes configurados es de la plataforma.

Este artículo sigue el camino que hace un agente web desde una URL pegada hasta un widget en el sitio del cliente, qué construye Wenui por su cuenta, qué toma de la plataforma y cómo cada cliente nuevo llega ya configurado. Es la versión larga de una idea de por qué cada cliente debería ser un tenant propio: un tenant puede ser la cuenta de un cliente, y también puede ser un producto entero con clientes propios.

Qué construye el producto y qué pone la plataforma

La división es la primera decisión de diseño y todo lo demás sale de ahí. Wenui construye todo lo que ve un visitante y cada regla propia de su negocio. La plataforma pone todo lo que sería igual para cualquier producto que corra agentes para muchos clientes.

El servidor de Wenui habla con la plataforma por su API pública, con una credencial para su parte del árbol de tenants: las mismas llamadas que haría cualquier empresa que construya un producto. Por eso la columna de la izquierda es chica: un equipo de producto escribe lo que es único de su producto y configura el resto.

Un árbol de tenants, muchos clientes configurados

Todo lo que hace Wenui pasa dentro de un subárbol. Arriba está el tenant de Wenui. Debajo cuelgan un tenant para los previews —los asistentes que se arman para visitantes que todavía no se registraron— y un tenant hijo por cada cliente que paga.

En esa forma vive la mayor parte de la configuración. La base de conocimiento, el agente, las claves, el saldo y los usuarios de un cliente están en su propio tenant, así que cada cliente de Wenui tiene desde el primer minuto el mismo aislamiento que la plataforma da a cualquier tenant. Los previews viven aparte de los clientes, así que el tráfico anónimo y los clientes que pagan nunca comparten espacio.

La configuración se resuelve de lo más cercano hacia arriba. Wenui escribe un valor una vez en su tenant —un límite, una tarifa, un destino para las invitaciones— y todos los clientes de abajo lo heredan. Cuando un cliente necesita algo distinto, el valor se escribe en ese cliente y cambia solo ese cliente. Un producto con mil clientes tiene un lugar para los valores por defecto y un lugar por cliente para las excepciones.

La facturación sigue el mismo recorrido. A un tenant que no define su tarifa se le cobra la del ancestro más cercano, así que un producto fija su margen una vez arriba y cada cliente nuevo se crea con su precio ya puesto.

De una URL a un agente en unos treinta segundos

El preview es todo el argumento de venta del producto, así que es lo que más vale la pena hacer bien.

1. Primero se revisa la dirección. Solo direcciones web públicas, sin credenciales, nada que resuelva a una red privada.
2. La plataforma lee el sitio. Wenui pide una fuente web sobre una base de conocimiento nueva y el crawler de la plataforma hace el resto: respeta las reglas de robots, sigue los sitemaps, fija la respuesta DNS pública al socket con el que se conecta, renderiza la página en un navegador aislado cuando el HTML resulta ser una cáscara vacía, y conserva como contenido los datos del negocio: un teléfono publicado, una dirección, los horarios. Cada chunk conserva la URL de la página de la que salió.
3. Wenui aplica su propia vara de calidad. Un sitio con muy poco texto se rechaza y su base de conocimiento se borra. Ese umbral es una regla de Wenui, así que vive en Wenui.
4. Wenui crea su propio agente. La definición es de Wenui: un guardrail para intentos de inyección y jailbreak que bloquea el turno si el verificador no está disponible —la entrada es pública y anónima—, un modelo rápido para responder, una guía de tono corta y la instrucción de ofrecer el contacto del negocio cuando el sitio no tiene la respuesta.
5. El visitante conversa. El servidor de Wenui reenvía cada turno con una sesión atada a ese visitante y a ese preview, le pone un tope de una docena de mensajes y devuelve la respuesta en streaming, a medida que se escribe.

En nuestras mediciones sobre el crawler compartido, un sitio de 25 páginas pasa de la dirección al agente respondiendo en unos 35 segundos. Dos horas después, el agente y la base del preview se limpian.

Un cliente configurado entero, en una sola secuencia

Cuando el visitante confirma su correo, Wenui da de alta un cliente. Cada paso es una llamada común, y cada uno se puede repetir sin riesgo:

• Un tenant hijo bajo el de Wenui, creado —o reutilizado si un intento anterior quedó por la mitad— y heredando todo lo configurado arriba.
• Un saldo prepago, que arranca en cero, listo para la primera recarga.
• El conocimiento que el visitante ya aprobó. La foto del preview se copia a una fuente web nueva en el tenant del cliente; la plataforma comprueba que la fuente, la base y el tenant van juntos y calcula los hashes contra los que comparan las sincronizaciones siguientes. La próxima sincronización parte de esos documentos, así que el sitio se lee una sola vez.
• El agente, con la misma definición que usó el preview.
• Una clave pública hecha para una sola tarea. Pertenece a un tenant, tiene rol de solo lectura y funciona solo en el canal de chat web y para ese agente. Wenui la guarda cifrada, así que un reintento devuelve la misma clave.
• Una invitación para el dueño, que crea la identidad y le deja elegir una contraseña o vincular un inicio de sesión que ya tenga.

Si falla la creación de los documentos o del agente, la base nueva se revierte y la secuencia puede correr de nuevo desde el principio. Todos los clientes salen iguales de ahí, y eso es lo que permite que un producto crezca sin una persona en el alta.

Su propia puerta de entrada

Un producto necesita su propia dirección, y sus clientes tienen que sentir que están en ese producto desde la primera pantalla hasta la última.

La consola en el dominio de Wenui. La plataforma sirve su consola de administración en un hostname adicional configurado para un subárbol de tenants. En ese hostname cada pedido queda acotado a ese subárbol: los usuarios ven sus propios tenants, los pedidos por algo de afuera se rechazan y los endpoints públicos sin un tenant reconocible quedan cerrados. El hostname lleva el nombre del producto, y encima puede ir el branding propio de cada tenant.

Su propio inicio de sesión. Wenui tiene su propio cliente sobre el pool de identidad compartido, con su propio branding de login —los colores de Wenui, el logo de Wenui— y callbacks exactos a sus dominios. La plataforma acepta tokens de ese cliente adicional para el mismo emisor. Las mismas identidades, los mismos permisos por tenant, la puerta de entrada del producto.

Invitaciones que vuelven a casa. Cuando la plataforma manda una invitación, necesita saber dónde configura su cuenta la persona. Los destinos son configuración del despliegue, indexada por tenant, y una invitación toma la del ancestro configurado más cercano. La invitación de un cliente de Wenui llega a la página de alta de Wenui porque ese cliente cuelga del tenant de Wenui. El próximo producto configura su propia entrada y obtiene el mismo comportamiento.

Un portal que es el producto. La mayoría de los clientes no necesita la consola de administración. El portal de Wenui los hace ingresar con el flujo de código de autorización y PKCE a través de su propio servidor, muestra los tenants donde son dueños y les da tres cosas: el fragmento de código terminado con su clave adentro, su saldo y un botón para recargar. La consola queda disponible para quien quiera ajustar su agente en detalle.

Pago por uso, listo para usar

Wenui vende pago por uso con saldo prepago, y el manejo del dinero viene con la plataforma.

La recarga abre el checkout del proveedor de pagos desde la sesión del propio cliente. Cuando el pago se confirma, el webhook de la plataforma acredita el saldo una vez por checkout, con un bloqueo sobre ese saldo, incluidos los medios de pago que se acreditan más tarde. El portal después le pregunta a la plataforma si ese checkout se acreditó, así que la confirmación que ve el cliente es la de su compra. El runtime revisa el saldo del tenant antes de responder, así que el primer mensaje después de la acreditación pasa solo.

Configuración, no código

Todo lo que es de Wenui vive en Wenui o en configuración: su hostname, su cliente de login, sus callbacks y su destino de invitaciones son entradas del despliegue, y su tono, sus reglas y su vara de calidad están en su propio servidor. El código de la plataforma es el mismo que corre en cualquier instalación.

Es a propósito, y rinde dos veces. Wenui avanza a su propio ritmo, porque cambiar el producto nunca espera una versión de la plataforma. Y cada vez que Wenui necesitó algo nuevo —destinos para las invitaciones, un segundo cliente de login, la consola en su propio dominio—, se construyó como una capacidad genérica que cualquier tenant puede configurar. La próxima empresa que arme un producto sobre la plataforma arranca con las tres ya disponibles.

Qué se configura a mano hoy

• Los dominios adicionales los configura un operador: un cambio de configuración revisado por dominio, con su certificado y su aceptación. Todavía no hay una pantalla de autoservicio para eso.
• La página de pago muestra la identidad comercial de la cuenta que cobra, en lugar de la del producto.
• Los montos de recarga son una sola lista para la instalación. Las listas por tenant están pedidas.
• La página de inicio de sesión se sirve desde el dominio de autenticación de la plataforma, con el branding propio de cada cliente.

Siete propiedades de una plataforma sobre la que se puede construir un producto

Lo construyas sobre esta plataforma o sobre otra, estas son las propiedades que deciden qué tan rápido puede crecer un producto con muchos clientes: un punto cada una.

1. Tu producto funciona sobre APIs públicas y versionadas, así que tu equipo escribe producto y no parches de integración.
2. Cada uno de tus clientes recibe el aislamiento de la propia plataforma desde el momento en que se crea.
3. Fijás un valor una vez para todos tus clientes —una tarifa, un límite, un destino— y lo cambiás para uno cuando hace falta.
4. Podés emitir una credencial que haga exactamente una cosa, para un agente, en un canal.
5. Tu producto vive en su propio dominio y con su propio inicio de sesión, así que tus clientes se quedan dentro de tu marca.
6. Los pagos se confirman solos a través de la plataforma, una vez por compra, listos para que tu portal los muestre.
7. Lo que tu producto necesita llega como configuración, y cada capacidad construida para un producto queda para el siguiente.