Esta es la primera entrada de una serie de casos de estudio de ingeniería sobre los productos que construyo. La idea no es vender — es abrir el capó y mostrar el porqué detrás de las decisiones técnicas: el contexto, el stack, los trade-offs, la arquitectura, y hasta una idea aproximada de costo y tiempo.
Empezamos con Plixiq, un producto que cofundé.
¿Qué es Plixiq?
Plixiq es una plataforma multi-tenant para correr agentes de soporte con IA en WhatsApp, con escalación fluida a agentes humanos. Una empresa configura un agente de IA — su personalidad, el tono de su marca, sus reglas de escalación —, conecta un número de WhatsApp, y desde ese momento el agente responde a los clientes 24/7. Cuando una conversación necesita a un humano (un cliente molesto, un reembolso, lo que sea que las reglas marquen), Plixiq la transfiere a un agente disponible y mantiene todo el intercambio en un solo lugar.
El problema que resuelve es mundano pero costoso: el soporte en WhatsApp no escala con la nómina. Los equipos o pagan personas para vigilar un buzón de chat las 24 horas, o los clientes esperan. Plixiq absorbe el 80% repetitivo con IA y enruta el 20% difícil a humanos — sin perder el contexto en la transferencia.
Está pensado para agencias y negocios que necesitan una mesa de soporte híbrida IA + humano, con cada cliente aislado como su propio tenant.
El stack, y por qué
Cada elección de abajo se hizo para optimizar las mismas dos cosas: velocidad de desarrollo para un equipo pequeño y type safety de punta a punta. Esta es la versión corta, con el razonamiento.
Async-first, tipado con Pydantic, ideal para el manejo de mensajes en tiempo real.
SQLAlchemy + Pydantic en uno — un solo modelo en vez de un modelo ORM y un schema aparte.
Escala bien; Neon agrega branching de base de datos para entornos de preview por PR.
Esquema versionado, compatible con async.
Una sola interfaz para muchos proveedores, con fallback y reintentos incorporados.
Cola sobre Redis, ligera y async-native — un Celery moderno y más pequeño.
Cachea la config del agente, respalda la cola de trabajos y propaga eventos en tiempo real.
JWT en cookie HttpOnly, con roles RBAC de fábrica.
SSR, un proxy /api del mismo origen para que las cookies "funcionen solas", y optimización de imágenes.
Type safety innegociable.
Errores tipados y reintentos — cada servicio devuelve Effect<T, TypedError> en vez de lanzar excepciones.
Estilos utility-first sobre primitivas accesibles y sin estilo.
Actualizaciones en vivo unidireccionales sin el peso operativo de WebSockets.
Despliegues por Git, secretos y entornos de preview automáticos por PR.
Una rama de base de datos desechable por pull request — los previews tienen datos reales y aislados.
Lint, import-linter y tests en cada PR antes de poder mergear.
Un detalle pequeño pero revelador: la capa de LLM usa Groq por defecto (rápido y gratis) y cae a OpenAI solo cuando Groq falla. LiteLLM convierte eso en una línea de configuración en vez de una rama de código — que es exactamente para lo que está.
Arquitectura
Plixiq es un monolito modular: un solo backend desplegable, dividido internamente en diez contextos acotados (bounded contexts) independientes (identidad, mensajería, conversación, escalación, configuración de agentes, etc.). Cada contexto expone una API pública pequeña y no puede meterse en las entrañas de otro — una regla que se hace cumplir en CI con import-linter, no con buenas intenciones.
Arquitectura general. Un mensaje de WhatsApp entra por la Cloud API de Meta, el backend FastAPI lo pasa por el pipeline de mensajes y el gateway LiteLLM, y los agentes humanos ven todo en vivo desde el panel de Next.js vía SSE.
¿Por qué un monolito y no microservicios? Con un equipo pequeño, el impuesto operativo de los microservicios (red, despliegue, tracing distribuido, consistencia de datos) aporta muy poco al inicio. El monolito modular conserva las fronteras limpias de los microservicios — para que el sistema pudiera dividirse después — manteniendo la simplicidad operativa de un solo despliegue hoy.
Cómo se procesa un mensaje
El corazón de Plixiq es el pipeline que convierte un mensaje entrante de WhatsApp en una respuesta. Es un flujo lineal con una sola bifurcación: la transferencia a un humano.
El pipeline de mensaje, paso a paso. La mayoría de los mensajes fluye directo hacia una respuesta de IA; la rama punteada es donde una conversación se entrega a un humano.
Recorriéndolo:
- Webhook de entrada — Meta envía el mensaje. Verificamos la firma HMAC, aplicamos rate-limit y resolvemos a qué tenant pertenece el número de WhatsApp.
- Guarda de entrada — un clasificador de IA filtra abuso y spam antes de gastar un token, y se obtiene-o-crea la conversación.
- Construir el prompt — la configuración del agente se trae de un caché en Redis (para no golpear la base de datos en cada mensaje) y se compone con el historial y el contexto de marca.
- Llamada al LLM — vía LiteLLM: Groq primero, OpenAI como fallback.
- Chequeo de escalación — palabras clave más sentimiento deciden si se necesita un humano y si está disponible dentro de su límite de concurrencia.
- Guarda de salida — la respuesta se valida (idioma, formato, longitud) y se persiste junto con su conteo de tokens.
- Enviar respuesta — de vuelta por la Cloud API de WhatsApp, se publica un evento SSE al panel y se programan los temporizadores de seguimiento/cierre automático.
Cuando se dispara la escalación, la conversación pasa a WITH_HUMAN, se asigna por round-robin a un agente disponible y — si está activado — un proxy de WhatsApp conecta al humano y al cliente directamente hasta que el agente la cierra.
Modelo de datos y multi-tenancy
El multi-tenancy es la columna vertebral: cada agente, conversación y mensaje pertenece a una Organización. Esa única regla de alcance es lo que permite que un solo despliegue sirva con seguridad a muchos clientes aislados.
Las entidades centrales. Todo lo que está dentro de la frontera punteada pertenece a un solo tenant.
Algunas decisiones que vale la pena resaltar:
- Los roles son explícitos —
SUPER_ADMIN,ADMIN,HUMAN_AGENT— y la autenticación viaja en una cookie HttpOnly, así que el token nunca queda expuesto a JavaScript. - El estado de la conversación es una máquina de estados pequeña —
ACTIVE → WITH_HUMAN → CLOSED— que mantiene honesta la lógica de escalación y cierre automático. - El uso de tokens se guarda por mensaje, que es lo que hace posible, más adelante, reportar costos por tenant.
Tiempo real sin WebSockets
El panel tiene que sentirse vivo: un mensaje nuevo del cliente debe aparecer al instante para el agente humano. El instinto es ir por WebSockets, pero Plixiq usa Server-Sent Events en su lugar. El tráfico es casi por completo unidireccional (servidor → panel), y SSE te da eso sobre HTTP plano, con reconexión automática y sin infraestructura extra. El backend propaga los eventos por pub/sub de Redis; el frontend solo mantiene un EventSource abierto. Menos que operar, menos modos de falla.
Construyendo con IA
La IA aparece dos veces en este proyecto — en el producto y en el proceso.
En el producto, los LLM hacen más que responder: un modelo en Groq alimenta las respuestas del agente, un clasificador actúa como la guarda de entrada de seguridad, y el análisis de sentimiento alimenta el detector de escalación. Incluso se usan modelos locales (Ollama) para simular conversaciones de clientes durante las pruebas.
En el proceso, el código se construyó con uso intensivo de pair-programming con IA. La lección interesante no fue que la IA escribe código rápido — fue que la IA te acelera más cuando el proyecto tiene barandas fuertes. Las reglas de arquitectura forzadas en CI (import-linter, tests de arquitectura) hicieron que un asistente de IA pudiera moverse rápido sin erosionar en silencio las fronteras entre módulos. La estructura es lo que hace seguro desarrollar con IA a velocidad.
Cuánto cuesta operarlo
Los costos escalan casi por completo con el uso de LLM y el volumen de mensajes — la infraestructura en sí es barata. Estas son estimaciones aproximadas, de orden de magnitud, para un despliegue en producción; no son facturas:
| Escenario | Estimado mensual | Notas |
|---|---|---|
| Inicio / bajo volumen | ~$60–80 | Tier gratis de Groq, tiers gratis de Neon + Upstash, un servicio pequeño de Railway por lado |
| Medio (~10k conversaciones) | ~$150–250 | Base de datos de pago, uso del fallback de OpenAI, las tarifas por mensaje de WhatsApp empiezan a pesar |
| Alto (100k+ conversaciones) | $500+ | Los costos por mensaje de LLM y WhatsApp dominan; la infra sigue siendo despreciable |
El titular: una startup puede operar esto por el precio de un par de almuerzos al mes, y la curva de costo la domina un uso que solo pagas cuando ya tienes clientes.
Tiempos
Plixiq pasó de cero a un MVP casi completo en aproximadamente cuatro meses de trabajo a tiempo parcial, alcanzando ~40k líneas entre backend y frontend, diez bounded contexts y una suite de tests que vigila la arquitectura en CI. La arquitectura evolucionó deliberadamente en sitio — empezando como un monolito directo y refactorizándose en uno modular a medida que las fronteras se aclaraban — en vez de sobre-diseñarse de entrada.
Conclusiones
Si tuviera que comprimir esto en unas pocas lecciones transferibles:
- Elige un gateway, no un proveedor. LiteLLM convirtió "¿cuál LLM?" de un compromiso arquitectónico en un valor de configuración con fallback gratis.
- El monolito modular es el punto justo para un equipo pequeño: fronteras de microservicio, operación de monolito.
- Haz cumplir tu arquitectura en CI. Las reglas que no se verifican son sugerencias — y son las que te dejan (a ti y a tu asistente de IA) ir rápido sin hacer un desastre.
- Usa la herramienta de tiempo real más simple que sirva. SSE le ganó a WebSockets aquí porque el problema era unidireccional.
En la próxima entrega de esta serie haré el mismo desarme con otro proyecto del trabajo que he construido. Si hay una decisión específica aquí en la que quieras que profundice, hablemos.
