Architecture of an AI system for automated social media publishing

Generating text with artificial intelligence is relatively easy.

Turning it into content consistent with an organisation’s identity, adapting it to different channels, converting it into images and videos and publishing it without manual intervention, on the other hand, requires a carefully designed system.

For Fundacja Moje Podl@sie we built an automation able to manage the entire process of creating and distributing social content: from choosing the format to generating the graphics, through to preparing the materials intended for LinkedIn, Facebook, Instagram and YouTube.

The stack, in short: Make orchestrates the flow, a fast model like Groq generates the structured text, a serverless renderer on Vercel (Satori + resvg-wasm) produces the graphics and FFmpeg composes the videos.

The heart of the project is not a single AI model.

It is the software built around the model to make the result usable, recognisable and compatible with the different platforms.

The challenge: generating a post was not enough

The foundation needed to communicate more consistently without having to prepare every piece of content by hand.

The traditional process required several steps:

• choosing the topic;
• writing the text;
• deciding whether to use a single post or a carousel;
• splitting the content across the various slides;
• preparing the graphics;
• adapting the files to the requirements of each social network;
• creating a video format for YouTube;
• scheduling the publication.

Automating only the writing would have solved a limited part of the problem.

Text on its own is not yet content ready to be published. It must have an appropriate structure, respect the foundation’s visual identity and reach the platforms in the right format.

That is why we built a custom serverless renderer: a service able to receive the content produced by the AI and turn it into branded images ready for distribution.

How it works: the pipeline from Groq to Satori, through to publication

The process starts with content generation.

The language model (Groq) analyses the topic and returns a structure that includes title, text, caption, hashtags and recommended format.

Depending on the complexity of the subject it can choose between:

• a single post, suited to a short and immediate message;
• a carousel, useful when the content needs to be split across several points.

This choice is not left to the design stage. It is already present in the structure generated by the AI and is interpreted by the software.

The automation then coordinates the various components, prepares the images, converts the necessary formats and sends the content to the publishing modules.

The result is a single flow in which text, design and distribution are managed in a coordinated way.

An architecture split into precise responsibilities

To avoid a single component having to handle logic, layout and distribution all at once, we split the renderer into several endpoints.

Each part of the system has a specific function.

The first endpoint interprets the content and builds the sequence of slides.

The second actually generates the images.

A third component uses the graphics produced to create a video intended for YouTube.

This separation makes the system easier to control and lets us change one part without having to rewrite the entire flow.

The structured output: from Groq’s JSON to the slides

The endpoint dedicated to composition receives the JSON generated by the model (Groq).

Its job is to understand which format was chosen and turn the response into a structure ready to be rendered.

When the requested format is a carousel, the system builds:

• a cover;
• one slide for each point (usually 5 to 7 in total);
• a closing slide with a call to action.

When the content does not require several steps, a single card is generated.

The component also prepares the information the platforms need: title, caption, hashtags, full text and the URLs of the images in the different formats.

It does not create the graphic files directly. Instead it builds the addresses that call the renderer, so each URL already returns the corresponding image.

This lets the automation pass the files to the social channels without having to save, rename or convert them by hand.

Handling the imperfect outputs of artificial intelligence

A language model does not always return a structure that perfectly matches the specification.

It may add a Markdown block, insert a sentence before the JSON or produce an extra character.

In a demo this may seem like a detail. In an automated system it can break the entire process.

That is why we added a tolerant parser, designed to fix some of the most common errors before the content is processed.

The parser can, for example:

• remove the Markdown delimiters;
• isolate the JSON from the surrounding text;
• handle characters added accidentally;
• recover a valid structure when the output is not perfectly clean.

The goal is not to accept any response, but to stop small formal inaccuracies from blocking an otherwise correct flow.

It is one of the least visible aspects of the project, but also one of the most important for its day-to-day operation.

From text to image with Satori and resvg-wasm, without a browser

Graphics generation is handled by a second endpoint.

The renderer receives the card’s content, inserts it into the template and returns an image directly.

To build it we chose an approach based on Satori and resvg-wasm.

Satori turns the layout into an SVG file. Then resvg-wasm converts the vector into a PNG or JPEG image.

This means the system does not have to start Chromium, use a headless browser or capture a screenshot of a web page.

Rendering happens directly on the server.

This choice reduces the number of dependencies required and makes the process suited to a serverless environment like Vercel.

The template is first generated in vector format, so the text stays nice and sharp even when the image is produced at a higher resolution.

A visual identity built into the code

The graphics are not generated from a different visual model each time.

The foundation’s design has been turned into a system of reusable templates.

The main combination uses:

• a dark background;
• red as the accent colour;
• readable typography;
• monospace elements to reinforce the technological character;
• a consistent structure across covers, points and call to action.

Each type of slide has a precise function.

The cover introduces the topic.

The middle slides highlight the individual concepts through numbering, title and text.

The closing slide wraps up the story and directs the user towards the next action.

Several graphic variants have also been prepared, so the system can stay consistent without necessarily producing an identical composition for every piece of content.

The design, in this case, is not applied after generation. It is part of the software architecture.

The problem of Polish characters

One of the most delicate technical details concerned the fonts.

The foundation’s content includes Polish characters such as ą, ę, ł, ń and ś.

Not every font file contains the full set of characters. Versions meant for the basic Latin alphabet may not properly include the extensions needed for Polish.

To avoid missing symbols or wrong substitutions, the renderer loads the latin and latin-ext variants separately.

The two versions are registered under distinct names, so the rendering engine can use both without treating them as duplicates.

We also added a retry mechanism for loading the fonts from the CDN, reducing the chance that a temporary network issue produces an incomplete graphic.

It is an example of how a language requirement can become an architectural decision.

Vector icons without external dependencies

The system includes a library of duotone icons associated with themes such as technology, security, education, networking, environment and collaboration.

The AI can select the most suitable icon through a dedicated field.

The icons are embedded directly in the project as inline SVG.

There is therefore no need to call an external service or download a file during rendering.

This reduces network requests and limits the risk that an unavailable resource compromises the image.

The icon remains optional in any case: when it is not present, the layout keeps its structure without leaving empty spaces or producing errors.

PNG, JPEG and different requirements

Social platforms do not always handle files in the same way.

For LinkedIn and Facebook the system can use the PNG images produced by the renderer.

For Instagram a JPEG version is also generated, needed to meet the requirements of its publishing flow.

Both versions come from the same template and the same content. There is therefore no need to duplicate the composition or run external conversions.

The format is selected through an endpoint parameter and the image is returned directly with the correct MIME type.

The renderer also applies a 24-hour cache, avoiding needlessly rebuilding the same graphic when the URL is requested several times.

From slides to a 1080×1080 video with FFmpeg

The project also includes an endpoint dedicated to video generation.

The cards produced by the renderer are collected and turned into a sequence through FFmpeg.

The system merges the cards into a square 1080×1080 video, adds a music track and creates content ready for the foundation’s YouTube channel.

This way the same content can be adapted to a different format without having to rebuild the material by hand.

The images remain the main visual source, while the video component takes care of their timing composition and the audio.

This approach allows the same editorial core to be reused across several channels while keeping visual continuity.

Why a serverless architecture

The renderer was deployed on Vercel using a Node.js runtime and including the WebAssembly module needed for rasterisation.

The serverless choice is consistent with the volume expected for the project.

The foundation publishes on a scheduled frequency (one run every two days), so there is no need to keep a dedicated server constantly running.

The system runs when needed and can stay idle between one publication and the next.

A cold start of a few seconds has no significant impact on a process that runs in the background and does not require an immediate response to the user.

This architecture keeps the infrastructure relatively simple and appropriate to the real use of the project.

It would not automatically be the right choice for every application. In a system with continuous rendering or real-time requests, different decisions might be needed.

Why a custom renderer and not a ready-made tool (Satori vs APITemplate vs Blotato)

There are ready-made services to generate social graphics from templates, such as APITemplate, or platforms that also cover video and publishing, such as Blotato. They are great for getting started quickly. For a system that has to represent an organisation’s identity and be reusable across several projects, however, we chose a proprietary renderer based on Satori.

The difference, in short:

With a proprietary renderer the design becomes versioned code: we can add a new organisation by changing a few tokens (logo, colours, fonts) without rebuilding the automation, keep every graphic pixel-consistent and avoid depending on a vendor’s catalogue. It is the right choice when the system has to be reusable, not a single experiment.

How automation coordinates the system

The renderer does not work on its own. Make coordinates the steps between the AI model, the graphics service and the publishing platforms, moving information between components and triggering operations in the intended order: the model generates the content, the composition endpoint interprets its structure, the renderer produces the images, the video component prepares the YouTube format and the social modules finally receive ready-made text and files.

The system's autonomy also depends on handling the steps that would normally require manual intervention. In our case the system has to:

• interpret the AI output;
• correct some formal imperfections;
• choose the right graphic structure;
• split the content into slides;
• apply the visual identity;
• handle Polish characters;
• produce formats compatible with the different channels;
• create a video version;
• deliver the materials to the publishing modules.

Generating the text is therefore only the beginning. Autonomy comes from the combination of rules, checks and components that allow the content to move through the entire process without being rebuilt manually at each step.

Artificial intelligence and social projects

In a social organisation, technology should stay proportionate to operational needs.

The aim of this project was not to increase the number of tools used, but to reduce the work needed to keep the foundation’s digital communication active.

Choosing to generate graphics through controlled templates makes it possible to maintain a recognisable identity.

The ability to publish across several channels reduces the duplication of work.

The presence of an automated system also makes it possible to maintain a more regular frequency without requiring the manual preparation of every single piece of content.

The AI is therefore used as a component of a broader editorial process, not as a substitute for the foundation’s identity or objectives.

The value is not in the model, but in the system

A language model can generate a headline, some text or a list of points.

But it does not automatically know the format required by Instagram, the visual structure of a carousel, the limits of a YouTube title or the correct way to render Polish characters.

These aspects have to be translated into software.

This is where a project moves from experimentation to a usable tool.

The model produces raw material.

The system checks it, organises it, transforms it and delivers it in the correct format.

The real numbers of the system

In concrete terms, for Fundacja Moje Podl@sie the system produces:

• carousel slides at 1080×1080 pixels, 5 to 7 per carousel;
• images in PNG for LinkedIn and Facebook, in JPEG for Instagram, from the same template;
• a square 1080×1080 video with a music track for YouTube;
• a 24-hour cache on the renderer, to avoid regenerating the same graphic;
• a scheduled run every two days, at the cost of a few Make credits.

The result: from an entirely manual process to 15 pieces of content a month created and published autonomously on LinkedIn, Facebook, Instagram and YouTube.

In summary

For Fundacja Moje Podl@sie we built a system that does not just generate content.

The automation chooses the format, builds the sequence of slides, produces branded images, prepares the files for the different platforms and creates a video version intended for YouTube.

The custom serverless renderer is the link between the AI’s text output and the final content.

It is the component that turns a response generated by a model into a visual element consistent with the foundation’s identity and ready to be distributed.

Artificial intelligence starts the process.

The software built around it makes everything that comes next possible.