O Marketing Automation gera para nove redes, e nada vai ao ar sem aprovação

Um post por dia não é um post por dia. É nove. LinkedIn pede um tom, Instagram pede outro, TikTok pede um terceiro, e cada rede carrega dimensão de imagem, limite de caractere e regra de hashtag próprios. Fazer isso à mão, todo dia, para mais de um negócio ao mesmo tempo, ocupa um time inteiro e ainda atrasa.

Montei o Marketing Automation justamente para rodar mais de um negócio no mesmo pipeline. A pergunta que guiou o desenho não foi se a IA consegue escrever um post. Foi se dá para gerar e agendar conteúdo em nove redes sem abrir mão do controle editorial.

O gargalo nunca foi escrever o texto

Redigir um rascunho de post é a parte que ficou barata. Um modelo escreve dez versões em segundos, e isso sozinho não muda nada na operação: o texto ainda precisa virar nove peças diferentes, passar por alguém e entrar num calendário.

O trabalho de verdade estava no fluxo inteiro — gerar, adaptar por plataforma, aprovar, agendar — e no fato de que ele trava em qualquer um desses quatro pontos. Um rascunho parado esperando aprovação atrasa nove publicações de uma vez. Um adaptador que erra a proporção da imagem manda a peça errada para a rede errada.

Por isso o ponto de controle humano é obrigatório e vem antes de tudo. Quem publica é o Buffer, não o modelo. Nada sai do dashboard sem alguém clicar em aprovar, e essa foi a primeira regra escrita do sistema, não a última.

Dois modelos por peça, uma fila no meio e o Buffer no fim

O frontend é Next.js e concentra duas coisas: o dashboard de aprovação e o calendário editorial. É onde o material aparece pronto para revisão, com as variações de cada rede lado a lado. O backend é FastAPI e só orquestra — recebe o pedido, distribui as tarefas, devolve o resultado quando termina.

A geração usa dois modelos com papéis separados. O ChatGPT, da OpenAI, escreve o texto; o Gemini gera a imagem. Não é o mesmo modelo fazendo as duas coisas, e a divisão importa porque as duas chamadas têm custo, latência e modo de falha diferentes. Texto ruim você reescreve. Imagem com proporção errada você descarta inteira.

Entre o pedido e o resultado existe uma fila. Celery e Redis processam a geração de forma assíncrona, porque um único pedido vira nove variações de plataforma e ninguém deve ficar olhando uma tela travada enquanto isso roda. A pessoa pede, a interface responde, as peças vão chegando.

Depois da geração entram os adaptadores de plataforma, que reformatam cada peça para o destino dela: dimensão de imagem, limite de caractere, hashtag. O Buffer faz o agendamento final. E uma suíte com mais de 97 testes de frontend segura a parte que mais quebra em silêncio — a tela de aprovação, que é exatamente onde o humano decide.

Numa fila assíncrona, o que surpreende não é o modelo

Pipeline de geração com fila costuma surpreender em duas frentes, e nenhuma delas tem a ver com a qualidade do texto que sai.

A primeira é a fila crescer mais rápido do que o worker consegue processar. Cada pedido vira nove tarefas, e nove parece pouco até alguém aprovar uma semana inteira de calendário de uma vez. Aí o Redis acumula, o Celery devolve no ritmo dele, e a leitura de quem está na frente da tela é sempre a mesma: quebrou. Não quebrou. Está na fila, e a diferença entre as duas coisas precisa aparecer na interface.

A segunda é o adaptador de plataforma. Cada rede muda regra por conta própria: limite de caractere, proporção de imagem, o que conta como hashtag válida. A mudança não chega por aviso prévio, chega por peça rejeitada. E como o adaptador roda no fim do fluxo, o erro aparece depois da aprovação — no momento em que todo mundo já tratou aquele conteúdo como pronto.

O custo aqui é chamada de modelo, e ele multiplica por nove

A conta desse sistema não se parece com a de um pipeline de dados, em que a IA não decide nada e o gasto é infraestrutura ligada. Aqui cada peça de conteúdo custa duas chamadas de modelo — uma para o texto, outra para a imagem — e essas duas chamadas se multiplicam pelas nove variações de plataforma. O número que dói não é o preço da chamada. É o multiplicador.

Some a infraestrutura que não desliga. Celery e Redis precisam estar de pé mesmo quando ninguém está gerando nada, porque a fila é o que segura o dia de pico sem travar a interface. Worker ocioso também custa.

O sistema está em build, com a fase 1 completa. Não é produção estável, e eu não tenho um número de custo mensal para mostrar — tenho a forma da conta, que é o que serve para quem vai desenhar algo parecido. Se o seu volume for de uma peça por semana, a fila é exagero e o custo fixo não se paga. Se for calendário editorial de vários negócios ao mesmo tempo, ela é justamente o que evita o travamento.

Eu mediria o custo por peça publicada antes de ligar a décima rede

Com nove plataformas e dois modelos por peça, o número que merece instrumentação cedo é o custo por peça que efetivamente foi ao ar. Não por peça gerada. Por peça publicada.

A diferença não é detalhe. Boa parte do que o pipeline produz morre na aprovação, e é exatamente isso que se espera de um ponto de controle humano funcionando. Só que cada descarte já pagou duas chamadas de modelo, vezes o número de redes para as quais aquela peça foi adaptada. Sem essa medida, aumentar o volume parece barato, e só deixa de parecer quando a fatura chega.

Medir isso é contabilidade chata, não engenharia de IA: contar chamada por peça, marcar quais peças foram aprovadas, dividir. É o que responde se vale ligar mais uma rede ou se vale gerar menos e aprovar mais.

O que esse sistema resolve nunca foi "IA que escreve post". Foi o fluxo completo — gerar, aprovar, agendar — capaz de transformar uma ideia em nove peças formatadas para nove destinos, com uma pessoa no único ponto em que a decisão importa: antes de qualquer coisa ir ao ar. Tire o humano dali e você não ganha velocidade. Ganha nove erros de uma vez.