Building a Content Repurposing Engine: One Article, Nine Assets

Every content team has been sold the same demo. Paste an article, get a carousel, three quote cards, a script and a newsletter. It works. Then you look at the nine assets and realise they all lead with the same sentence, because they were all generated from the same summary, and the audience on each platform is being handed the identical thing in a different shape.

Reach did not go up. You just made nine copies.

Why the naive version flattens

The naive engine has one step: summarise, then reformat. Summarisation is lossy by design, so every downstream asset inherits the same compression, which means the same opening claim, the same three points, the same ending.

The fix is to stop summarising. Extract instead.

The architecture that works

Four stages. The first two are the ones people skip.

Stage 1: Decompose into claims

Read the source and produce a structured list of every distinct claim it makes, each with its supporting evidence, its strength, and how surprising it is. Not a summary. An inventory. A decent 1,500-word article yields somewhere between eight and twenty claims.

This is the step that makes everything downstream different, because now nine assets can lead with nine different claims rather than nine renderings of the strongest one.

Stage 2: Match claims to formats

Formats have appetites. A carousel wants a counter-intuitive claim with three supports. A quote card wants one sentence that survives without context. A short video wants a claim with a visual consequence. A newsletter wants the claim that is most useful to somebody who already trusts you.

Encode that as a specification per format rather than as a prompt, so the matching is inspectable. When an asset underperforms you can see which claim it was carrying and whether the format was wrong or the claim was.

Stage 3: Draft against the format specification

Now generate, one asset at a time, with the claim and the format spec as inputs and the source article available for evidence. This is where the agentic part earns its cost, because a source article never arrives in the same structure twice.

Stage 4: The deterministic tail

Naming, versioning, aspect-ratio export, alt text, scheduling, the run log. None of this needs judgement and all of it needs to be identical every time. Script it.

What nine assets should actually be

Where these engines break

• —No claim inventory. Everything flattens, as above. This is the failure in maybe eighty per cent of the repurposing systems we have been asked to look at.
• —No human gate. Nine assets a day, unreviewed, is nine times the surface area for a claim nobody substantiated. A person approves the claim inventory once per source. That is one review, not nine.
• —No naming convention. The system works beautifully for six weeks and then nobody can find the September assets.
• —No cost ledger. "It saves time" is not auditable. Cost per accepted asset is.
• —Repurposing something that should not have been published once. An engine amplifies whatever it is fed, including a weak argument.

The realistic gain

The honest number is not "ten times the content". It is that the coordination work collapses. The drafting was never the expensive part; the expensive part was the four hours a week spent renaming files, reformatting the same argument, chasing an approval and rebuilding a deck that already existed.

A repurposing engine that removes that and leaves the judgement alone is worth building. One that removes the judgement produces nine assets a week that nobody wants to put their name on.