The repurposing machine: one reel becomes three posts while you sleep, Quentin IA Marketing

The problem is not making content, it is redistributing it

You film a reel. It goes out on Instagram. And it dies there, when the exact same content could have lived on YouTube, on X, and as a carousel.

Doing it by hand works for a few weeks. Then one Sunday evening you skip your turn, and the system you were holding up by force of will stops.

Content that already exists should never require a second decision.

Here is the system I run. I post one reel on Instagram. A machine picks it up and turns it into three more publications. Over the last fifty days, ninety nine Shorts went out without me touching anything.

Claude AI Lab

The Claude AI Lab is my Skool community where I share my Claude systems and the more advanced modules. Access is $67/month.

Join the Lab →

✅What you need

An automation tool that runs continuously. n8n, Make, or your own code. What matters is that it does not live on your laptop, otherwise nothing ships when you close the lid.

A professional Instagram account. The Graph API only talks to business or creator accounts, and it is what gives you access to your own posts.

The destination API access. YouTube Data API for Shorts, the X API for video. Budget a few hours for the authorisation flows, it is the most tedious part.

An external table. Airtable, Sheets, a database, it does not matter. It stores what has already been processed. It is the most important piece of the system and I get to it immediately.

A notification channel. Telegram does the job well. It tells you what happened, and more importantly it asks for your call when one is needed.

Start with memory, not with publishing

🗂️ Airtable, Sheets, or a database

Everyone starts with the fun part: plug in the API and publish. That is the mistake that costs the most, because a system without memory republishes the same content in a loop and makes you look like a broken robot.

The first thing to build is a table that answers exactly one question: what have I already processed.

⚙️What the table needs to hold

The source content ID. The Instagram ID of the reel, not its title, not its caption. An ID never changes.

The source timestamp. It works as a cursor: the system processes anything newer than the last row written.

What got created. The YouTube video ID, the post link. So you can check later without guessing.

The status. Published, skipped, rejected. A skipped item has to say why, otherwise you will never know whether the system is working or asleep.

State lives in the table, never inside the automation itself. That is what lets you break a workflow, rebuild it, move it to another server, and never lose track of what has already been published.

The rule

A failed run should cost nothing. If state is external, you rerun it and the system picks up exactly where it stopped.

Fetching the reel

📥 Instagram Graph API

The system reads the cursor from the table, asks Instagram for your list of posts, and keeps the oldest one it has not processed yet.

Why the oldest and not the newest: because a YouTube channel that fills up in reverse is unreadable. Starting from the beginning makes your backfill read like a progression.

Then comes the trap nobody documents.

⏳

Instagram sometimes replies without the file

The API returns the post, with its ID and its type, but no video file URL. The media exists, it is simply not exposed yet.

🔁

The fix is waiting, not patching

That same item fetches perfectly a few minutes later. Plan for a delayed retry rather than a hard failure.

Add a duration check before you download anything. A forty minute live replay has no business being a Short, and you do not want to find that out after the download.

Worth remembering

Check duration before downloading, never after. A check placed too late turns a simple exclusion into a noisy failure.

The video repost

▶️ YouTube Data API

This is the simplest part, and the one that produces the most volume. The video already exists, it has already been approved, it has already been watched. Republishing it requires no decision.

Only one thing deserves real work: the title.

An Instagram caption is not a YouTube title. The caption speaks to someone who already follows you, the title speaks to someone who does not know you and is scanning a list. I have a fast model rewrite the title, with a short instruction: one hook, one emoji up front, nothing else.

🚫

The characters that break the upload

YouTube rejects angle brackets in the title and description. A model will produce them eventually. Strip them before sending, every time.

🎯

One download per day

Never download your whole backlog at once. One run, one video, and the file disappears after the upload. Nothing stored, nothing to clean.

The X post

✖️ X API, chunked upload

Publishing video on X takes more work than anywhere else. The file goes up in pieces, in three stages: you open the upload, you push the chunks, you close the upload.

And this is where the most expensive trap in the system hides.

⚠️The media is not ready when you think it is

Closing the upload does not mean it is done. X replies that the media is still processing, with an explicit state field.

A fixed wait is not enough. Wait fifteen seconds then publish and it works most of the time. Then one day it does not, and you cannot see why, because the video that fails is sometimes smaller than the one that went through.

Poll the state, do not assume it. Ask for the media status again until it is ready, with a capped number of attempts. That is three extra nodes and it removes the failure permanently.

Second point, specific to X: the link. A link in the body of the post reduces its reach. So the system publishes the video on its own, then drops the link as the first reply a few seconds later.

The general principle

Any time a platform answers "in progress", treat it as a question to ask again, not as a delay to guess.

Turning it into a carousel

🎠 transcribe, rewrite, render

Republishing a video is a copy. Turning it into a carousel is a rewrite, and a rewrite can get it wrong. This is the only step that needs a human.

⚙️The full chain

Transcribe. A transcription model turns the spoken content back into text. That is the real content of the reel, not its caption.

Rewrite. A model turns that text into about ten slides, with an enforced output format so the result is usable straight away.

Draw. A headless browser on the server turns each slide into an image. Your machine is never involved.

Ask. The system sends you the preview and waits for your answer. Until you reply, nothing ships.

Publish later. An approval at midnight should not trigger a midnight post. The system holds until the scheduled hour.

Be honest about what this implies. On my side, the half that needs nobody sits at ninety nine publications. The half that needs my approval is stuck at three, with twenty six previews waiting in my Telegram.

The bottleneck was never the machine. It was me.

That is useful information, not a failure. It tells you exactly where to spend your effort: either you approve more often, or you shrink the part that needs approving.

The guardrails

🛡️ five rules

An automated system is judged on what it refuses to do, not on what it does.

🙋

Nothing rewritten ships without approval

A copy can be automatic. A rewrite waits for a human.

🔒

Never the same content twice

Every run reads the cursor first. Repeats become impossible, not just unlikely.

⏱️

Refuse anything over a set length

Anything past three minutes is not short form and does not ship.

🧹

One download a day, nothing kept

No archive, no folder filling up, nothing to clean later.

💻

No dependency on your computer

Everything lives on a small server. You close it all, it keeps running.

The order to build it in

Do not build all three outputs at once. You will spend a week debugging three things at the same time and never ship any of them.

🧱Five steps, in this order

Do one repost by hand. Once, clicking through it. You discover the real formats and the real constraints.

Put it on a clock. One run a day, one output, and the table that remembers.

Add the rules that stop it. Duration, exclusions, missing file. They matter more than the feature.

Add a second output. Only then, once the first has run unattended for several days.

Add the part that needs you last. The rewrite, with its approval step. It is the most fragile piece, it comes at the end.

The real lesson

Rules are not an add-on to automation, they are the product. A machine that publishes without guardrails gives back in repairs the time it saved you.

What it actually changes

The win is not the time saved, real as that is. The win is that redistribution stops being a decision.

As long as republishing requires a judgement call, you will not do it consistently. Nobody does. Once it is a machine with clear rules, it happens every day, including the days you do not feel like doing anything.

And the day you look at your numbers, you learn something useful about how you operate: what runs on its own moves forward, what waits on you stops. That is true well beyond content.