Saltar al contenido
Air Automations
Todos los posts
Estrategia8 de julio de 2026Lectura de 6 minutos

Adaptadores de SDK de Chat de Eve: Implementación Fácil, Decisiones Difíciles

El SDK de Chat de Eve hace que los despliegues de agentes multi-superficie sean plug-and-play. Esto es lo que los equipos pierden de vista: límites de velocidad por plataforma, divergencia de estado y cuándo gana un webhook.

By the airautomations team

El cableado se hizo fácil. La decisión se hizo más difícil.

Los adaptadores de canal del SDK de Chat de Eve para Slack, WhatsApp, Teams, SMS y widget web solían requerir un sprint de plomería. Verificación de firma de webhook, bucles de actualización de tokens, flujos de autenticación por plataforma, normalización de mensajes — todo. Luego lo enviarías y pasarías tres meses descubriendo que los límites de velocidad de Slack no se componen de la misma manera que los de WhatsApp.

Eso se acabó. Un adaptador de canal es un archivo de configuración. Vercel Connect maneja la actualización de OAuth y el almacenamiento de credenciales de forma transparente. El trabajo aburrido — lo que consumía tiempo de calendario — se acabó.

Lo que significa que el cuello de botella se movió. Ya no debatirás si construir la integración. Debatirás si deberías. No todas las superficies de chat merecen un agente. Algunas merecen un webhook. Algunas no merecen nada.

La lógica del controlador no es portátil: qué se rompe entre Slack y WhatsApp

Un único controlador `on_message` que funciona en Slack fallará silenciosamente o ruidosamente en WhatsApp. No porque el código sea incorrecto, sino porque las superficies tienen restricciones incompatibles.

Los métodos de nivel 2/3 de la API web de Slack tienen un límite de aproximadamente 20 solicitudes por minuto. La API en la nube de WhatsApp limita el flujo de mensajes salientes a 80 mensajes por segundo para tráfico iniciado por la empresa, pero también está limitado a una ventana de sesión de 24 horas — después de eso, solo se pueden enviar mensajes de plantilla, y esos requieren aprobación previa. SMS tiene un límite de 160 caracteres por segmento; Slack acepta 40k caracteres; WhatsApp llega hasta 4096. Un usuario de Slack espera un plazo de reconocimiento de interacción de 3 segundos para clics de botón. Los webhooks de WhatsApp se reintentan hasta que reciben un 200 OK, y no se agota el tiempo de espera de la misma manera.

Un controlador que alegremente llama a un LLM y escribe una respuesta de 8k caracteres funciona bien en web y Slack. Se trunca silenciosamente en WhatsApp y falla en SMS. Si no instrumentas por adaptador, descubrirás esto en producción.

Cada adaptador necesita su propia política de reintentos, curva de retroceso y lógica de idempotencia. WhatsApp reentregará mensajes entrantes si no reconoces dentro de una ventana. Slack también lo hará en 5xx, pero la semántica de reintentos difiere. SMS no tiene recibos de lectura o indicadores de escritura, por lo que la suposición de tu controlador sobre "esperar una respuesta" se rompe inmediatamente.

Las herramientas hicieron que el despliegue fuera sin fricción. No aplanaron las superficies en sí.

La gestión de estado diverge por modelo de hilo

Slack tiene `thread_ts` como una clave de conversación natural. Un DM, un mensaje de canal, una respuesta de hilo — cada uno tiene un alcance diferente, pero el modelo de hilo es explícito. WhatsApp no tiene hilos. El número de teléfono es la única clave. Tú posees el ventaneo: ¿es un mensaje de hace 3 horas parte de la misma conversación o uno nuevo? SMS no tiene concepto de hilos o sesiones en absoluto. Teams te da `conversation.id` más `activity.id`, con alcance de inquilino implícito.

Una abstracción compartida de `conversation_id` que se asigne en las cuatro superficies es una trampa. Silenciosamente fusiona el DM de Slack de un usuario con su hilo de WhatsApp si no tienes cuidado con el alcance. El patrón canónico que hemos visto funcionar: transcripción duradera en Postgres, ventana activa en Redis con clave por identificadores de superficie específica (thread_ts de Slack, phone_number + window_start de WhatsApp, conversation.id de Teams), cada una con un TTL específico de superficie. La ventana de conversación de WhatsApp podría ser de 30 minutos. Un hilo de Slack vive más tiempo. SMS no tiene ventana nativa, así que eliges una (generalmente 5–15 minutos para flujos transaccionales).

La divergencia de estado no es un error que captures en staging. Es un invariante de tiempo de ejecución que tienes que hacer cumplir en el código.

No todas las superficies merecen un agente

Esta es la conversación difícil. Las notificaciones SMS y pings de estado — "Pedido #4521 enviado" o "Confirmar: sí/no" — no necesitan un LLM. Un webhook plantillado vence a un agente por 100x en costo y latencia. Estás pagando $0.002 por llamada de GPT-4o-mini para una respuesta determinista que un regex de 5ms maneja. Los disparadores de `/command` de Slack a menudo son una única llamada de herramienta, no un bucle de razonamiento — un flujo de trabajo gana.

El soporte al cliente de WhatsApp con búsqueda de documentos es territorio legítimo de agente. Multi-turno, uso de herramientas, RAG — el agente se gana su lugar. Un widget de chat web en tu página de precios puede ser un agente, pero necesita protecciones pesadas (presupuesto de tokens, filtrado de salida, alcance de herramientas). ¿Notificaciones internas de Slack? Webhook. ¿Flujo de calificación de ventas en WhatsApp? Agente.

La lente que funciona: si la interacción es de un solo disparo o plantillada, usa un webhook. Si requiere razonamiento multi-turno y uso de herramientas, usa un agente. Aplica esto por canal, no por producto. Podrías tener un agente en WhatsApp y un webhook en SMS para el mismo problema empresarial. Eso es correcto.

Las matemáticas de latencia y costo también importan. Los usuarios de WhatsApp toleran 3–5 segundos. Los usuarios interactivos de Slack quieren latencia subsegundo. Si tu presupuesto de latencia es 500ms y el LLM tarda 1.5s, el adaptador se está ejecutando en tiempo prestado. Cuando estés activando una nueva superficie, la primera pregunta debería ser: ¿realmente esta interacción necesita razonamiento, o necesito enviar esto rápido?

La rotación de credenciales se resolvió. La observabilidad no.

Vercel Connect maneja la actualización de OAuth, el almacenamiento de tokens y el alcance de credenciales por inquilino — la plomería que solía consumir una semana. Lo que no te da es visibilidad en la salud por adaptador.

Instrumenta cada adaptador con cuatro métricas: tasa de 2xx de webhook entrante, latencia p95 del controlador, tasa de error de llamada de herramienta y éxito de envío saliente. No compartas una cola de letra muerta en superficies. Los reintentos de WhatsApp funcionan de manera diferente a los de Slack; fusionarlos en una cola significa que manejarás fallos transitorios de Slack con la curva de retroceso exponencial de WhatsApp, lo cual es incorrecto.

La propagación de ID de rastreo desde el webhook entrante a través del bucle del agente hasta el envío saliente importa más en agentes multi-superficie que en bots de un solo canal. Cuando un mensaje desaparece en WhatsApp pero tiene éxito en Slack, necesitas seguirlo a través de adaptadores. La mayoría de las plataformas de observabilidad lo hacen difícil porque asumen una única fuente de eventos.

Vercel Connect solucionó el dolor de cabeza de autenticación. No dejes que la rotación de credenciales sea tu excusa para omitir telemetría por canal. La observabilidad del agente en producción es un problema de operaciones, no un problema de credenciales.

Una lista de verificación de decisiones antes de activar un nuevo adaptador

Antes de habilitar WhatsApp, Teams o SMS para tu agente:

  • ¿Es la interacción multi-turno o de un solo disparo? Un solo disparo → webhook.
  • ¿Cuál es el límite de velocidad de la plataforma y cómo se compone con el TPM de tu proveedor de LLM? (Si los 80 msg/seg de WhatsApp y tu TPM de OpenAI entran en conflicto, tienes un problema.)
  • ¿Dónde vive el estado y cuál es el TTL? (Postgres + Redis con clave por superficie específica, o filtras contexto.)
  • ¿Cuál es el plan de respaldo cuando el modelo agota el tiempo dentro de la ventana de reconocimiento de la plataforma?
  • ¿Quién es responsable de las alertas de rotación de credenciales cuando Vercel Connect expone un fallo de actualización?
  • ¿Hay un proceso de plantilla o aprobación (WhatsApp, iMessage Business) que bloquee la salida de forma libre?

Esta lista de verificación parece sencilla. En la práctica, la mayoría de los equipos aprenden estas restricciones enviando y luego apagando incendios. Saber si necesitas un agente o un flujo de trabajo es la mitad de la batalla. La otra mitad es saber qué superficies realmente justifican la complejidad.

Si estás a mitad de la implementación y la lista de verificación anterior generó más preguntas que respuestas, esa es la conversación que tenemos la mayoría de las semanas. Comunícate en /contact antes de activar el siguiente adaptador.