We built an internal content pipeline to turn selected articles from a founder's personal site into reviewed English posts for AImpress. The interesting part was not generating text. It was making a multi-system workflow safe enough to operate without wondering whether one click had published something twice.
The workflow
n8n orchestrates the process. A scheduled workflow checks the source sitemap, normalises URLs and ignores records already known to NocoDB. New articles are extracted and classified before they enter the publishing queue.
A preparation workflow selects the next eligible record in a deterministic order. It translates the article, generates audio, prepares the cover image and sends a Telegram approval card. The owner can approve or reject the result without entering an administration interface.
On approval, a separate workflow publishes to the AImpress blog and then prepares posts for LinkedIn and Facebook through Postiz. NocoDB stores the operational record.
The failure that changed the design
The early version treated publication as one uninterrupted action. If the blog accepted a post but a later social step failed, the database did not necessarily show what had already succeeded. Repeating the approval could duplicate content.
We separated preparation from approval, added guards and began persisting the blog URL before retrying the social stage. Before creating a blog post, the workflow now checks the public blog index for an existing match. Telegram error messages restore the approval controls and explain whether a remote result is confirmed or uncertain.
Why retries are not always safe
Retries are appropriate for reads and idempotent updates. They are dangerous for a publish request when the remote service may have accepted the operation before the connection timed out. The workflow retries safe calls with backoff, but does not blindly repeat blog or social publication.
Human approval remains deliberate
Automation prepares the material, but a person remains responsible for whether it should represent the company. This boundary protects tone, facts and timing while still removing most mechanical work.
What we learned
The useful architecture emerged from tracing state across systems, not from selecting an AI model. Deterministic ordering, explicit error paths, honest operator messages and reconciliation matter more than a polished happy-path demo.
This is the standard we apply to client automation: understand what has already happened, make repeated actions safe where possible and keep a person in control of consequential decisions.