VoxxFlow

Agencies and marketing teams serve several companies and several brands at once, and each one needs strategy, an editorial calendar, copy, media, review, publication and reporting. Handing that whole chain to AI models without supervision is risky, because generated text should not go live before a person has approved it.

VoxxFlow is a multi-tenant digital marketing platform. Each subscriber works in an isolated environment, with its own plan, modules and team. Work is organized in four levels, tenant (the subscriber), client, brand and campaign, and the brand holds the identity that the agents follow: tone of voice, hashtags, key messages, banned words and content language.

The platform brings together:

• 12 user-facing agents in four groups: editorial pipeline (6), growth (4), commercial (1) and visibility in AI assistants (1);
• strategy brainstorming by conversation, in two formats: brand onboarding and campaign;
• an editorial calendar, content creation and review, with generation and translation in Portuguese, English and Spanish;
• a media library with AI analysis and an AI Studio that generates images and videos;
• publication to Instagram and Facebook;
• metrics collected once a day, A/B tests, reports with AI-written analysis, and AEO (answer engine optimization), which prepares content to be cited by assistants such as ChatGPT, Claude, Gemini and Perplexity.

The editorial cycle moves forward through human decisions:

• The Strategist agent leads the brainstorm. When a person approves the campaign strategy, the Planner generates the editorial calendar.
• When a person approves the calendar, the Creator writes the content for each post. Without that approval, no post receives text.
• The Reviewer gives a verdict on each post (approved, revision needed or rejected), and the person decides: approve, ask for a revision or reject.
• The Publisher prepares the publication, fixing the caption and media, and then executes it on the network.

Only posts approved by a person enter publication. After approval, an automatic service checks pending publications every 5 minutes and publishes those whose scheduled time has arrived.

The agents do not run tools on their own: the application code interprets each model response and decides what to write to the database. If the response cannot become a readable caption, or if the AI is down, the generation fails without saving anything and without consuming credits.

Every infrastructure change goes through Terraform: plan, read the whole plan, and only then apply. Nothing goes through the AWS console, because a change made there is not recorded in Terraform’s state, and the next apply would silently revert it. The state lives in an encrypted S3 bucket with native locking. The code declares the network, the host, the managed PostgreSQL 16 database with no public access, the load balancer with TLS, the certificate, DNS, the private media bucket and the permissions.

Behind the load balancer, a single host runs five containers: backend, frontend, two queue workers and Redis. The two workers consume separate queues, one for batches and scheduled tasks and the other for interactive tasks such as AEO, AI Studio, brainstorming and translation. Without the interactive worker, those tasks sit in the queue with no visible error, which is why the post-deploy check confirms both. Server access is through an AWS Systems Manager session authorized by IAM, and no administration port is open.

Images are never built on the server. On every push to the main branch, GitHub Actions workflows build the backend and frontend images, each only when its own code changed, and publish them to the AWS container registry with two tags: the commit SHA and prod. The frontend build needs about 3 GB of memory. Built on the server that runs the application, it pushed the load average to 42, and the backend processes were killed three times in 20 minutes. With a ready-made image, the load average for the same deploy stayed at 0.10.

The deploy procedure follows this order:

• Authorization: a production deploy happens only with explicit authorization.
• Check: a script confirms that CI has already published the image for the latest commit. Without that check, the pull would fetch the previous image, the command would finish successfully and production would keep running the old code.
• Deploy: update the repository, which also brings the compose file, pull the images and recreate the containers. The backend and the workers go up together, because they use the same image. Database migrations run on their own when the backend starts.
• Verification: services up, health endpoint answering, migration at the expected point and each worker announcing the queue it consumes.
• Rollback: point the prod tag back at the good commit and pull the image. The registry keeps the last ten images. Moving the tag takes the administrator credential, and the CI credential is deliberately not allowed to do it.

The repository’s MCP servers, which wrap the backend API and the Meta API, run locally against the public API and are not part of the production deployment.

VoxxFlow is in production and serves agencies and marketing departments, including those that serve several companies or run several brands. Sign-up offers a 14-day trial with no credit card. Four plans, Starter, Professional, Agency and Enterprise, limit clients, brands, campaigns, users, storage and AI credits, which range from 100 to 10,000 a month. The platform’s 21 modules are included according to the plan, and those left out can be bought separately.

VoxxFlow is Sigil Labs’ own product and supports three service lines. In Service as Software, AI agents do the work of an agency under human approval. In AI and LLM work, the agents write, review and analyze the content. In infrastructure, the operation described above is the production example of that service.