VoxxFlow

Agências e times de marketing atendem várias empresas e várias marcas ao mesmo tempo, e cada uma pede estratégia, calendário editorial, textos, mídia, revisão, publicação e relatório. Entregar essa cadeia a modelos de IA sem supervisão é arriscado, porque texto gerado não deve ir ao ar sem que uma pessoa o tenha aprovado.

O VoxxFlow é uma plataforma multiempresa de marketing digital. Cada assinante opera em um ambiente isolado, com plano, módulos e equipe próprios. O trabalho se organiza em quatro níveis, tenant (o assinante), cliente, marca e campanha, e a marca guarda a identidade que os agentes seguem: tom de voz, hashtags, mensagens-chave, palavras proibidas e idioma do conteúdo.

A plataforma reúne:

• 12 agentes voltados ao usuário, em quatro grupos: pipeline editorial (6), crescimento (4), comercial (1) e visibilidade em assistentes de IA (1);
• brainstorm de estratégia por conversa, em dois formatos: onboarding de marca e campanha;
• calendário editorial, criação e revisão de conteúdo, com geração e tradução em português, inglês e espanhol;
• biblioteca de mídia com análise por IA e um AI Studio que gera imagens e vídeos;
• publicação no Instagram e no Facebook;
• métricas coletadas uma vez por dia, testes A/B, relatórios com análises escritas pela IA e AEO (otimização para mecanismos de resposta), que prepara o conteúdo para ser citado por assistentes como ChatGPT, Claude, Gemini e Perplexity.

O ciclo editorial avança por decisões humanas:

• O agente Estrategista conduz o brainstorm. Quando uma pessoa aprova a estratégia da campanha, o agente Planner (planejador) gera o calendário editorial.
• Quando uma pessoa aprova o calendário, o Creator escreve o conteúdo de cada post. Sem essa aprovação, nenhum post recebe texto.
• O Reviewer dá um veredito sobre cada post (aprovado, revisão necessária ou rejeitado), e a pessoa decide: aprovar, pedir revisão ou rejeitar.
• O Publisher prepara a publicação, fixando legenda e mídia, e depois a executa na rede.

Só posts aprovados por uma pessoa entram em publicação. Depois da aprovação, um serviço automático verifica as publicações pendentes a cada 5 minutos e publica as que já chegaram ao horário agendado.

Os agentes não executam ferramentas por conta própria. O código da aplicação interpreta cada resposta do modelo e decide o que gravar no banco. Se a resposta não puder virar uma legenda legível, ou se a IA estiver fora do ar, a geração falha sem gravar nada e sem consumir créditos.

Toda mudança de infraestrutura passa pelo Terraform: plano, leitura integral do plano e só então aplicação, nunca pelo console da AWS, porque uma alteração feita no console não entra no estado do Terraform, e a próxima aplicação a desfaria em silêncio. O estado fica em um bucket S3 criptografado, com bloqueio nativo de concorrência. O código declara a rede, o host, o banco PostgreSQL 16 gerenciado e sem acesso público, o balanceador de carga com TLS, o certificado, o DNS, o bucket privado de mídia e as permissões.

Atrás do balanceador, um único host executa cinco containers: backend, frontend, dois workers de fila e Redis. Os dois workers consomem filas separadas, uma para lotes e tarefas agendadas e outra para as tarefas interativas, como AEO, AI Studio, brainstorm e tradução. Sem o worker interativo, essas tarefas ficam na fila sem erro visível, e por isso a verificação pós-deploy confere os dois. O acesso ao servidor é feito por sessão do AWS Systems Manager, autorizada por IAM, e não há porta de administração aberta.

As imagens nunca são construídas no servidor. A cada push na branch principal, workflows do GitHub Actions constroem as imagens de backend e de frontend, cada um só quando o seu código mudou, e as publicam no registro de containers da AWS com duas tags: o SHA do commit e prod. O build do frontend precisa de cerca de 3 GB de memória. Construído no próprio servidor que atende a aplicação, o build elevou a carga média a 42, e os processos do backend foram encerrados três vezes em 20 minutos. Com a imagem pronta, a carga média do mesmo deploy ficou em 0,10.

O procedimento de deploy segue esta ordem:

• Autorização: deploy em produção só acontece com autorização explícita.
• Conferência: um script confirma que o CI já publicou a imagem do último commit. Sem essa conferência, o pull traria a imagem anterior, o comando terminaria com sucesso e a produção continuaria com o código velho.
• Deploy: atualizar o repositório, que também traz o arquivo de composição, baixar as imagens e recriar os containers. Backend e workers sobem juntos, porque usam a mesma imagem. As migrações de banco rodam sozinhas na inicialização do backend.
• Verificação: serviços no ar, endpoint de saúde respondendo, migração no ponto esperado e cada worker anunciando a fila que consome.
• Rollback: reapontar a tag prod para o commit bom e baixar a imagem. O registro guarda as dez últimas imagens. Reapontar a tag exige a credencial de administrador, e a do CI não tem essa permissão, de propósito.

Os servidores MCP do repositório, que dão acesso à API do backend e à API da Meta, rodam localmente contra a API pública e não fazem parte do deploy de produção.

O VoxxFlow está em produção e atende agências e departamentos de marketing, inclusive os que atendem várias empresas ou operam várias marcas. O cadastro oferece 14 dias de teste sem cartão de crédito. Quatro planos, Starter, Profissional, Agência e Enterprise, limitam clientes, marcas, campanhas, usuários, armazenamento e créditos de IA, que vão de 100 a 10.000 por mês. Os 21 módulos da plataforma são incluídos conforme o plano, e os que ficam de fora podem ser contratados à parte.

O VoxxFlow é produto próprio da Sigil Labs e sustenta três frentes de serviço. Em Service as Software, agentes de IA fazem o trabalho de uma agência sob aprovação humana. Em IA e LLM, os agentes escrevem, revisam e analisam o conteúdo. Em infraestrutura, a operação descrita acima é o exemplo em produção desse serviço.