VoxxFlow

Las agencias y los equipos de marketing atienden a varias empresas y varias marcas al mismo tiempo, y cada una pide estrategia, calendario editorial, textos, medios, revisión, publicación e informe. Entregar esa cadena a modelos de IA sin supervisión es arriesgado, porque un texto generado no debe salir al aire sin que una persona lo haya aprobado.

VoxxFlow es una plataforma multiempresa de marketing digital. Cada suscriptor opera en un entorno aislado, con plan, módulos y equipo propios. El trabajo se organiza en cuatro niveles, tenant (el suscriptor), cliente, marca y campaña, y la marca guarda la identidad que siguen los agentes: tono de voz, hashtags, mensajes clave, palabras prohibidas e idioma del contenido.

La plataforma reúne:

• 12 agentes orientados al usuario, en cuatro grupos: pipeline editorial (6), crecimiento (4), comercial (1) y visibilidad en asistentes de IA (1);
• brainstorm de estrategia por conversación, en dos formatos: onboarding de marca y campaña;
• calendario editorial, creación y revisión de contenido, con generación y traducción en portugués, inglés y español;
• biblioteca de medios con análisis por IA y un AI Studio que genera imágenes y videos;
• publicación en Instagram y Facebook;
• métricas recopiladas una vez al día, pruebas A/B, informes con análisis escritos por la IA y AEO (optimización para motores de respuesta), que prepara el contenido para que lo citen asistentes como ChatGPT, Claude, Gemini y Perplexity.

El ciclo editorial avanza por decisiones humanas:

• El agente Estratega conduce el brainstorm. Cuando una persona aprueba la estrategia de la campaña, el agente Planner (planificador) genera el calendario editorial.
• Cuando una persona aprueba el calendario, el Creator escribe el contenido de cada publicación. Sin esa aprobación, ninguna publicación recibe texto.
• El Reviewer emite un veredicto sobre cada publicación (aprobada, requiere revisión o rechazada), y la persona decide: aprobar, pedir revisión o rechazar.
• El Publisher prepara la publicación, fijando el texto de acompañamiento y los medios, y después la ejecuta en la red.

Solo las publicaciones aprobadas por una persona entran en el proceso de publicación. Después de la aprobación, un servicio automático revisa las publicaciones pendientes cada 5 minutos y publica las que ya llegaron a la hora programada.

Los agentes no ejecutan herramientas por su cuenta. El código de la aplicación interpreta cada respuesta del modelo y decide qué guardar en la base de datos. Si la respuesta no puede convertirse en un texto de acompañamiento legible, o si la IA está fuera de servicio, la generación falla sin guardar nada y sin consumir créditos.

Todo cambio de infraestructura pasa por Terraform: plan, lectura completa del plan y solo entonces aplicación, nunca por la consola de AWS, porque un cambio hecho en la consola no entra en el estado de Terraform, y la siguiente aplicación lo desharía en silencio. El estado queda en un bucket S3 cifrado, con bloqueo nativo de concurrencia. El código declara la red, el host, la base de datos PostgreSQL 16 administrada y sin acceso público, el balanceador de carga con TLS, el certificado, el DNS, el bucket privado de medios y los permisos.

Detrás del balanceador, un único host ejecuta cinco contenedores: backend, frontend, dos workers de cola y Redis. Los dos workers consumen colas separadas, una para lotes y tareas programadas y otra para las tareas interactivas, como AEO, AI Studio, brainstorm y traducción. Sin el worker interactivo, esas tareas quedan en la cola sin error visible, y por eso la verificación posterior al despliegue revisa los dos. El acceso al servidor se hace por sesión de AWS Systems Manager, autorizada por IAM, y no hay ningún puerto de administración abierto.

Las imágenes nunca se construyen en el servidor. En cada push a la rama principal, workflows de GitHub Actions construyen las imágenes de backend y de frontend, cada una solo cuando su código cambió, y las publican en el registro de contenedores de AWS con dos etiquetas: el SHA del commit y prod. El build del frontend necesita cerca de 3 GB de memoria. Construido en el propio servidor que atiende la aplicación, el build elevó la carga promedio a 42, y los procesos del backend se terminaron tres veces en 20 minutos. Con la imagen lista, la carga promedio del mismo despliegue quedó en 0,10.

El procedimiento de despliegue sigue este orden:

• Autorización: el despliegue en producción solo ocurre con autorización explícita.
• Comprobación: un script confirma que el CI ya publicó la imagen del último commit. Sin esa comprobación, el pull traería la imagen anterior, el comando terminaría con éxito y la producción seguiría con el código viejo.
• Despliegue: actualizar el repositorio, que también trae el archivo de composición, descargar las imágenes y recrear los contenedores. Backend y workers suben juntos, porque usan la misma imagen. Las migraciones de base de datos corren solas al iniciar el backend.
• Verificación: servicios en línea, endpoint de salud respondiendo, migración en el punto esperado y cada worker anunciando la cola que consume.
• Rollback: volver a apuntar la etiqueta prod al commit bueno y descargar la imagen. El registro guarda las diez últimas imágenes. Volver a apuntar la etiqueta exige la credencial de administrador, y la del CI no tiene ese permiso, a propósito.

Los servidores MCP del repositorio, que dan acceso a la API del backend y a la API de Meta, corren localmente contra la API pública y no forman parte del despliegue de producción.

VoxxFlow está en producción y atiende a agencias y departamentos de marketing, incluidos los que atienden a varias empresas u operan varias marcas. El registro ofrece 14 días de prueba sin tarjeta de crédito. Cuatro planes, Starter, Profesional, Agencia y Enterprise, limitan clientes, marcas, campañas, usuarios, almacenamiento y créditos de IA, que van de 100 a 10.000 por mes. Los 21 módulos de la plataforma se incluyen según el plan, y los que quedan fuera pueden contratarse por separado.

VoxxFlow es un producto propio de Sigil Labs y sostiene tres frentes de servicio. En Service as Software, agentes de IA hacen el trabajo de una agencia bajo aprobación humana. En IA y LLM, los agentes escriben, revisan y analizan el contenido. En infraestructura, la operación descrita arriba es el ejemplo en producción de ese servicio.