El agente marca a García como confirmado y la fila cambia

Una pareja escribe «marca a García como confirmado» en un asistente, y en la tabla guests cambia una fila. No se genera un borrador para que alguien lo apruebe. No sale una sugerencia. Cambia el dato. Ese es el momento exacto en que el diseño agéntico deja de ser una conversación sobre productividad y se convierte en otra cosa: hay un agente con las manos dentro del evento privado de dos personas que se casan una vez en la vida.

El caso es bodados.com, una plataforma nupcial con doble audiencia levantada por un fundador único desde el primer commit, en febrero de 2026. Cinco agentes con acción real autenticada: editan invitaciones, gestionan listas, generan presupuestos, contactan proveedores. La diferencia con el resto de la serie del Instituto es que aquí los agentes no son una capa lateral sobre un producto editorial. Son el producto. Y por eso el caso se documenta como inventario de decisiones, no como caso de éxito.

La decisión de la que cuelga todo lo demás no parece de diseño: la pareja paga 49 € una sola vez, no una cuota. Suena a pricing y es arquitectura. Una pareja organiza una boda en su vida; el SaaS mensual es absurdo cuando el evento tiene fecha fija. Al no haber suscripción desaparecen el flujo de renovación, el downgrade, el dunning, el análisis de churn y la pantalla donde se ruega al usuario que no se vaya. Un pago, hecho. El sistema entero adelgaza por una decisión que se tomó dos capas más arriba.

La otra decisión es de bando. En un sector donde los directorios cobran al proveedor por aparecer en un listado, sin ROI medible, bodados cobra a la pareja y paga al proveedor cuando hay transacción real. El producto lo dice sin adornos: «Bodas.net te cobra. Bodados te paga». Eso obliga a mantener dos superficies públicas con dos voces sobre el mismo worker, la de la pareja y la del profesional, sin que el sistema se parta en dos.

Quién gana y quién paga cuando el agente ejecuta. Gana la pareja, que se ahorra el Excel y el WhatsApp donde este sector lleva décadas atascado. Gana el proveedor, que cobra por resultado. Y paga el diseñador del sistema, que hereda un problema que no tenía: un chatbot que se inventa una respuesta hace el ridículo, pero un agente con acción real que se equivoca borra a un invitado de una boda. El coste del error deja de ser reputacional y pasa a ser un asiento vacío en un banquete.

De ahí sale la enseñanza que este caso deja y que ninguna herramienta resuelve por ti. Cuando el agente solo redacta, el design system puede permitirse la ambigüedad: alguien humano hará de filtro antes de que nada sea verdad. Cuando el agente escribe en la base de datos, cada ambigüedad del sistema es un fallo en producción esperando fecha. El vocabulario deja de ser documentación y se convierte en contrato.

Por eso el documento del caso empieza avisando de que no es un caso de éxito. Es un inventario. Y un inventario es lo único que sirve cuando la máquina ya no propone: ejecuta.