Cómo está hecho
Todas las agencias muestran un chat. Lo que hace distinta a esta vitrina es que también muestra lo de atrás: qué herramienta se llamó, qué validó la base, cuánto tardó y cuánto costó. Si podés ver eso, no hace falta que nos creas.
El recorrido de un mensaje
eventos, y eso es lo único que la
Vidriera sabe dibujar.
Las cuatro capas
HTML, CSS y JavaScript sin build step ni framework. Se abre el archivo y anda. Dos identidades visuales separadas: la de la agencia y la del cliente.
Funciones serverless en Vercel. El motor conversa con el modelo (Gemini o Claude, según la configuración), ejecuta herramientas y escribe la traza. Ninguna clave sale de acá.
Postgres con las reglas del negocio adentro, en funciones que corren en transacción, con RLS real y Realtime.
La única fuente de verdad. Precios, horarios y reglas viven ahí; el seed, la config del navegador y el prompt del agente se generan desde ese archivo.
El complejo también habla cuando nadie pregunta
Hasta acá todo arranca porque un jugador escribió. Pero la mitad del trabajo de un complejo es al revés: avisar. Que se liberó el turno que esperabas, que se te venció la seña, que el sábado va a llover.
Cuando una función de la base decide avisarle a alguien, escribe el mensaje en una cola dentro de la misma operación en que toma la decisión. O quedan las dos cosas, o no queda ninguna. Un proceso aparte vacía esa cola y manda.
Si no, se libera un turno para alguien que nunca se entera de que lo tenía.
Ese proceso aparte son tres flujos de n8n: uno corre las tareas periódicas cada cinco minutos, otro vacía la cola, y el tercero consulta el pronóstico. Ninguno decide a quién avisar ni arma el texto: eso sigue estando en la base, que es donde están todas las reglas. n8n solo transporta.
Por qué el agente no puede inventar un precio
Porque no tiene cómo. La herramienta de generar el link de pago recibe un
reserva_id y nada más: el monto lo lee la base. Si el modelo quisiera cobrar
otra cosa, no tiene ningún parámetro donde escribirlo.
Un modelo tiene un mal día. Una función no.
| herramienta | recibe del modelo | nunca recibe |
|---|---|---|
| reservar | cancha y horario | el teléfono ni el precio |
| cancelar | el código de reserva | si se devuelve la seña o no |
| generar_link_pago | el id de la reserva | el monto |
| escalar | un motivo de una lista cerrada | texto libre como motivo |
Qué pasa cuando algo falla
Si la base rechaza algo —el turno ya está tomado, la cancelación es tardía, el monto del pago no coincide— eso no se esconde: el nodo de la base se enciende en rojo y la fila del libro de a bordo dice por qué. Es la parte más honesta de la demostración, y por eso hay un escenario dedicado a mostrarla.
Si se cae la API del modelo, o se agota el presupuesto del día, la Vidriera pasa a modo grabado: reproduce una conversación guardada con sus tiempos reales y lo dice con un cartel. Nunca se muestra como vivo algo grabado.
Lo que se prueba, y cómo
Las reglas del negocio se prueban contra un Postgres descartable en Docker, nunca contra la nube. Después se rompen a propósito, una por una, y se exige que la suite se ponga en rojo: una suite que no puede fallar no sirve. El resultado de la última corrida, con su fecha y su commit, está en Qué se probó.
Vidriera · Apollo Dynamics. Complejo La Redonda es un cliente ficticio de demostración: los datos, los nombres y los teléfonos son inventados.