Taller Ghosty: cómo funciona un agente de WhatsApp multi-backend (grabación on-demand)

El Problema

Montar un agente serio sobre WhatsApp parece un día de trabajo — hasta que te toca hacerlo en producción.

La primera versión siempre funciona: un script, un webhook, tres mensajes de prueba. Después aparece la realidad y se vuelve un laberinto de preguntas que ningún tutorial resuelve completo:

• ¿Uso la WhatsApp Business API oficial (WABA) con su proceso de Meta, o voy self-hosted?
• ¿Cómo abstraigo el backend para poder cambiar de uno al otro sin reescribir el agente?
• ¿Qué pasa cuando el número pierde la sesión a las 3am y nadie está despierto para re-parearlo?
• ¿Dónde guardo el estado de las conversaciones, las credenciales, los media?
• ¿Cómo enruto mensajes entrantes a un LLM, a un humano, o a una cola según contexto?
• ¿Qué demonios es un template message y por qué Meta me lo rechaza?

La documentación oficial asume que solo te interesa WABA. Los tutoriales de self-hosted asumen que WABA no existe. Nadie te explica cómo armar una sola cosa que sirva para ambos — y ese es exactamente el problema que resuelve Ghosty.

La Solución

Ghosty: una arquitectura de agente multi-backend, con WABA y Baileys debajo del mismo código.

Ghosty (github.com/blissito/Open-Ghosty_Docker) no es "otra librería de WhatsApp". Es un patrón de diseño con Docker Compose encima: un agent runtime que habla con un provider adapter, y el adapter decide si la conversación sale por WABA oficial o por Baileys self-hosted. Tu código de agente no sabe la diferencia.

En el taller desarmamos cada capa:

• Agent runtime — el que decide qué responder. Aquí puedes enchufar un LLM, reglas de negocio, un clasificador de intents, o una mezcla. Es la única capa que te importa escribir.
• Provider adapter — traduce el formato interno del agente al de cada backend. send(message) se convierte en una llamada a la API de Meta o en un frame de Baileys, según cómo hayas configurado el entorno.
• Webhook gateway — recibe eventos (mensaje entrante, ACK, cambio de estado) y los normaliza al formato interno antes de pasárselos al agente.
• Session store — persiste las credenciales de Baileys y los tokens de WABA, porque perder el pairing es perder el negocio.

Por qué multi-backend importa. No es una feature cosmética: es la forma de no quedar casado con una decisión temprana. Empiezas en Baileys porque estás prototipando un MVP, validas que el agente funciona, y el día que el cliente enterprise pide WABA certificado — cambias el adapter, no el agente. Mismo código, mismo flujo, otra plomería.

La otra cara: WABA tiene ceremonia (approval de templates, tarifas por conversación, verificación del negocio). Baileys es instantáneo pero no oficial. Tener los dos en la misma arquitectura te deja elegir por escenario, no por lock-in.

A mitad del taller el droplet donde corría Ghosty dejó de aceptar la llave SSH. Lo dejé en vivo porque este tipo de cosas es exactamente lo que aprendes operando infra tuya:

"La key no es el problema, el authorized_keys quedó corrupto después de un edit. Consola web de DigitalOcean, ls -la /root/.ssh/, tail -30 /var/log/auth.log, y el log nos dice exactamente qué línea arreglar."

Diez minutos después Ghosty estaba corriendo de nuevo. Esa parte nunca la cubre un tutorial — y es la diferencia entre entender el sistema y solo seguir pasos.

El Resultado

1h 40min de grabación end-to-end, desde la arquitectura conceptual hasta el demo real.

Lo que se cubre y se lleva quien compra el acceso:

• ✅ Arquitectura Ghosty explicada — cómo interactúan agent runtime, provider adapter, webhook gateway y session store.
• ✅ Setup con Docker Compose — un solo archivo que levanta todo el stack, listo para clonar desde el repo público.
• ✅ Configuración de ambos backends — el entorno para arrancar con Baileys, y las variables/pasos para conectar WABA cuando estés listo.
• ✅ Pareo por QR y persistencia de sesión — el flujo real, no el happy path del README.
• ✅ Troubleshooting en vivo — SSH roto, logs de auth, recuperación sin destruir el droplet.
• ✅ Demo end-to-end — Ghosty respondiendo en un grupo de WhatsApp, cotizando un servicio y entregando la propuesta en PDF.

La demo importa porque cierra el loop: no es un "hola mundo", es un agente procesando contexto, decidiendo qué ofrecer, generando un documento y mandándolo por el mismo canal donde llegó el lead. Eso es lo que quieres operar tú — no lo que te venda un dashboard rentado.

Conclusión

El valor del taller no es "qué backend usar" — es entender la arquitectura que te permite cambiar de backend sin reescribir tu producto.

Si vas a construir algo sobre WhatsApp que te importe mantener durante años, necesitas separar qué responde tu agente de por dónde sale el mensaje. Ghosty es una muestra concreta de cómo se ve ese desacople en código, con Docker, con un repo público que puedes clonar hoy.

Si quieres la grabación completa del taller, accede al taller por $799 MXN — pago único, acceso permanente. Si eres de los que prefieren ver antes de comprar, el repo Open-Ghosty_Docker está público y arrancar un contenedor local toma 10 minutos.

¿Quieres más contenido sobre arquitectura de agentes y infra que controlas tú? Suscríbete al canal de YouTube de Héctorbliss donde compartimos los tropiezos reales detrás de cada proyecto.

Abrazo. bliss.